PR Summary

Medium Risk
Touches executor orchestration and execution-finalization/log persistence paths, which can affect run outcomes and logging correctness if sequencing or async behavior is wrong. Changes are guarded with try/catch and added tests, but include new DB writes and async callback awaiting that may impact timing.

Overview
Adds durable execution diagnostics to workflow_execution_logs, including lastStartedBlock, lastCompletedBlock, trace span presence/count, and a finalizationPath/completionFailure to explain how a run ended.

Refactors lifecycle signaling across BlockExecutor, loop/parallel orchestrators, and subflow-utils to await onBlockStart/onBlockComplete (including empty-subflow events) while swallowing callback failures so they don’t change execution outcomes.

Updates LoggingSession to persist last-started/last-completed markers via monotonic JSONB updates, track/drain pending “progress” writes before terminal completion, and ensure fallback completions preserve successful outputs and accumulated cost; ExecutionLogger now carries through existing diagnostics and computes trace span counts. Adds focused regression tests for ordering, fallback semantics, and empty-parallel lifecycle behavior.

^{Written by Cursor Bugbot for commit 767775c. Configure here.}

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 18, 2026 0:00am

Greptile Summary

This PR establishes a durable execution diagnostics foundation by persisting lastStartedBlock, lastCompletedBlock, finalizationPath, and completionFailure into workflow_execution_logs, and by converting the previously fire-and-forget post-execution logging in execution-core.ts into an awaited, centralized finalization step.

Key changes:

• logging-session.ts: Adds onBlockStart / onBlockComplete lifecycle hooks that issue monotonic JSONB jsonb_set writes per block, tracked in a pendingProgressWrites set that is drained before any terminal completion call.
• execution-core.ts: Replaces fire-and-forget void (async () => {})() finalization with await finalizeExecutionOutcome(...) / await finalizeExecutionError(...), ensuring DB writes complete before the function returns; introduces wasExecutionFinalizedByCore to prevent double-logging by outer callers.
• All orchestrators (block-executor, loop, parallel, node) and subflow-utils are updated to make their onBlockStart / onBlockComplete callbacks async and wrapped in try/catch so callback failures never break execution.
• diagnostics.ts (new): Provides buildExecutionDiagnostics for the upcoming read-surface — currently covered by tests but not yet wired to any route.
• types.ts: Adds ExecutionFinalizationPath, ExecutionLastStartedBlock, and ExecutionLastCompletedBlock types with a runtime type guard.

Notable behavior change: The response from executeWorkflowCore is now delayed until DB finalization writes complete, trading a small latency increase for guaranteed diagnostic durability.

Confidence Score: 4/5

• Safe to merge — no critical logic bugs found; changes are well-tested and isolated to the logging/diagnostics layer.
• The refactoring is thorough, backed by focused regression tests covering ordering invariants, retry semantics, and callback isolation. The main behavioral change (awaiting DB writes before returning) is intentional and correct. The noted issues are minor: countTraceSpans duplication, a snapshot-based drain that could theoretically miss late writes (practically safe given the execution model), a changed import style in logger.test.ts, and fire-and-forget cost flushes that are not tracked in pendingProgressWrites (safe because the terminal write uses in-memory cost). No runtime errors or data-loss scenarios were identified.
• Pay close attention to apps/sim/lib/logs/execution/logging-session.ts (drain semantics and cost flush fire-and-forget) and apps/sim/lib/workflows/executor/execution-core.ts (new awaited finalization path).

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant EC as executeWorkflowCore
    participant LS as LoggingSession
    participant DB as Database
    participant EX as Executor

    EC->>LS: safeStart()
    EC->>EX: execute() with wrappedOnBlockStart/Complete

    loop For each block
        EX->>EC: wrappedOnBlockStart(blockId, ...)
        EC->>LS: onBlockStart(blockId, startedAt)
        LS->>DB: jsonb_set lastStartedBlock (monotonic)
        DB-->>LS: ack (tracked in pendingProgressWrites)
        LS-->>EC: resolved
        EC-->>EX: void userCallback fired separately

        EX->>EC: wrappedOnBlockComplete(blockId, output)
        EC->>LS: onBlockComplete(blockId, output)
        LS->>DB: jsonb_set lastCompletedBlock (monotonic)
        LS->>DB: void flushAccumulatedCost (fire-and-forget)
        LS-->>EC: resolved
        EC-->>EX: void userCallback fired separately
    end

    EX-->>EC: ExecutionResult

    EC->>EC: finalizeExecutionOutcome()
    EC->>LS: safeComplete / safeCompleteWithCancellation / safeCompleteWithPause
    LS->>LS: drainPendingProgressWrites()
    LS->>DB: completeWorkflowExecution (finalizationPath, lastStarted/CompletedBlock, traceSpans)
    DB-->>LS: ack
    LS-->>EC: resolved

    EC->>DB: clearExecutionCancellation
    EC->>DB: updateWorkflowRunCounts
    EC-->>Caller: ExecutionResult

_{Last reviewed commit: 9db5e87}

@icecrasher321 I think this is an important one. One scenario I have experienced is stuck workflow. I couldn't find any logs, and it just kept in running. I am planning to introduce few more prs after this one too.

@icecrasher321 I think this is an important one. One scenario I have experienced is stuck workflow. I couldn't find any logs, and it just kept in running. I am planning to introduce few more prs after this one too.

Cool yeah, I'll review these. Thanks.

bugbot run